home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Graphics Plus
/
Graphics Plus.iso
/
amiga
/
viewers
/
shwvc306.lha
/
ShowVIC
/
Formats.doc
< prev
next >
Wrap
Text File
|
1993-08-28
|
5KB
|
170 lines
C64 PICTURE FORMATS
===================
By Matt Francis (m.p.francis@newcastle.ac.uk)
INTRODUCTION
------------
Several people have asked me to include information on the different picture
formats with this release of ShowVIC. Well, information wants to be free,
so here are details of all the formats ShowVIC supports. The following
labels are used:
Load - Load address (first two bytes of the file)
Length - File length in bytes (including load address bytes)
Bitmap - Bitmap offset (8000 bytes)
Screen - Screen data offset (1000 bytes)
Colour - Colour data offset (1000 bytes)
ScrCol - Screen colour offset (1 byte)
The offsets given for the bitmap, screen data etc. do not include the two
load address bytes.
NOTE: If you don't know anything about how the C64 stores bitmaps, you will
find it very hard to write a conversion program. If this is the case, I
recommend you read about bitmaps in a good C64 reference book before
attempting to write a conversion routine.
THE FORMATS
-----------
Art Studio (hires): Load - $2000
Length - 9009
Bitmap - 0
Screen - 8000
Image System (hires): Load - $4000
Length - 9194
Bitmap - 0
Screen - 8192
Blazing Paddles (multicolour): Load - $A000
Length - 10242
Bitmap - 0
Screen - 8192
Colour - 9216
ScrCol - 8064
Koala (multicolour): Load - $6000
Length - 10003
Bitmap - 0
Screen - 8000
Colour - 9000
ScrCol - 10000
Advanced Art Studio (multicolour): Load - $2000
Length - 10018
Bitmap - 0
Screen - 8000
Colour - 9016
ScrCol - 9001
Artist 64 (multicolour): Load - $4000
Length - 10242
Bitmap - 0
Screen - 8192
Colour - 9216
ScrCol - 10239
Vidcom 64 (multicolour): Load - $5800
Length - 10050
Bitmap - 2048
Screen - 1024
Colour - 0
ScrCol - 2024 (see note at end)
Image System (multicolour): Load - $3C00
Length - 10218
Bitmap - 1024
Screen - 9216
Colour - 0
ScrCol - 9215
Doodle (hires): Load - $5C00
Length - 9218
Bitmap - 1024
Screen - 0
FLI (see notes at end): Load - $3B00
Length - 17474 or 17666
Bitmap - 9472
Screen - 1280 (8000 bytes)
Colour - 256
ScrCol - 0 (200 bytes)
Hi-Eddi: Load - $2000
Length - 9218
Bitmap - 0
Screen - 8192
Amica-Paint: Compressed Koala pictures
SPECIAL NOTES ON VIDCOM
-----------------------
Unfortunately, Vidcom doesn't seem to store the screen colour in its bitmap
files. To get round this, ShowVIC takes the screen colour from offset 2024
($7E8), which is usually a zero (so Vidcom pictures will normally be
converted with a black background, even though Vidcom itself uses dark blue
by default). This can be changed by loading the picture into a binary file
editor like NewZap or DekSid, and changing byte 2026 (2024+2 for load
address bytes) to a value from 0 to 15. Of course, you could do this on a
C64 before actually transferring the picture. The best solution is to avoid
using the Vidcom format - Koala or Advanced Art Studio is preferable.
One more thing about Vidcom: it seems to use exactly the same format for
both hires and multicolour pictures, making it impossible to distinguish
between them. For this reason, ShowVIC currently assumes all Vidcom
pictures are multicolour. If many people badger me (can't see it
happening), I might add a switch in a later release, so you can choose which
mode to convert to.
SPECIAL NOTES ON FLI
--------------------
For a full description of FLI, I refer you to Pasi Ojala's article in issue
4 of the "C= Hacking" magazine. Here are a few notes on implementing the
format.
The only difference between converting this format and converting a normal
multicolour bitmap is that (a) the screen colour ($D021) changes every
scanline, and (b) every byte of every character block in the bitmap has its
own byte of screen data. The screen data is organised in 8 pages of 1000
bytes each. When an FLI picture is displayed on a C64, the screen RAM page
is changed every scanline, so the first pixel line of bytes (*not* the first
40 bytes) in the bitmap uses the first 40 bytes from the first page of
screen data. The second pixel line uses the first 40 bytes from the second
page of screen data, and so on. Hopefully this example will help clarify
things:
Byte in Char. Screen Screen
bitmap block data page data byte
-------------------------------------------------
0 0 0 0
1 0 1 0
... ... ... ...
7 0 7 0
8 1 0 1
9 1 1 1
... ... ... ...
15 1 7 1
16 2 0 2
... ... ... ...